Amazon Redshift Serverless Provisioned Clusterからのマイグレーション手順

データアナリティクス事業本部コンサルティングチームの石川です。本日は、既存のRedshift（Provisioned Cluster）からRedshift Serverlessへ移行する方法、その注意点について解説します。

マイグレーションのシナリオ

既存のRedshift（Provisioned Cluster）の環境と、Redshift Serverlessの環境について解説します。

既存のRedshift（Provisioned Cluster）の環境

既存のRedshift環境のVPCは、PublicとPrivateの２つ、２つのアベイラビリティゾーンの合計４つのサブネットから構成されます。

AWS環境構成図は、以下のとおりです。既存のRedshiftは、ra3.xlplusの2ノードクラスタ、サブネットグループは2つのPrivateサブネットのCross-AZ cluster recovery構成になっており、障害が発生しても別のPrivateサブネットで自動復旧します。よって、Redash（Redshiftを利用するサーバーアプリケーション）からは、Redshiftのエンドポイントに対して接続します。

Cross-AZ cluster recovery構成ついては、以下のブログをご覧ください。

移行後のRedshift Serverlessの環境

Redshiftクラスタ（Provisioned Cluster）とRedshift Serverlessの大きな違いは、ネットワークです。

Redshiftクラスタ（Provisioned Cluster）は、ノードタイプとそのノード数に応じて、プライベートIPアドレス（ENI）の確保が必要でした。一方、Redshift Serverlessは、RPU（Redshift Processing Unit）というコンピューティングを表す単位に対して相対的かつ動的にプライベートIPアドレス（ENI）が確保されます。今回は、サブネット毎に/20という広いCIDRを確保しているので問題ありません。

また、Redshift Serverlessは、少なくとも3つのサブネットが必要で、それらが3つのアベイラビリティゾーンにまたがっている必要があります。今回は、アベイラビリティゾーンのサブネットを追加することで、この要件に対応します。

よって、移行後のRedshift Serverless環境のVPCは、PublicとPrivateの２つ、３つのアベイラビリティゾーンの合計6つのサブネットから構成されます。

AWS環境構成図は、以下のとおりです。アベイラビリティゾーンのサブネット（PublicSubnet-cとPrivateSubnet-c）を追加しました。移行後のRedshift Serverlessは、サブネットグループの代わりに3つのアベイラビリティゾーンにまたがっている3つのサブネットを指定します。Redash（Redshiftを利用するサーバーアプリケーション）からは、Redshiftのエンドポイントに対して接続します。

Provisioned ClusterからRedshift Serverlessへのマイグレーション

以下の手順で、マイグレーションを実施します。

1. VPCに３アベイラビリティゾーンを跨ぐサブネットを構成する
2. 既存のRedshift（Provisioned Cluster）のスナップショットを取得する
3. リストア先のRedshift Serverlessの名前空間（Namespace）を作成する
4. Redshift Serverlessの名前空間を指定してスナップショットをリストアする
5. アプリケーションの設定（接続先のRedshiftのエンドポイントを変更する）

1. VPCに３つのアベイラビリティゾーンを跨ぐサブネットを構成する

既存のVPCが、３つのアベイラビリティゾーンを跨ぐサブネットを構成できない場合は、サブネットの再構成、もしくは新規にVPCを作成してください。

2. 既存のRedshift（Provisioned Cluster）のスナップショットを取得する

自動スナップショットと手動スナップショットのどちらからでもリストアは可能です。

3. リストア先のRedshift Serverlessの名前空間（Namespace）を作成する

スナップショットのリストアは、Redshift Serverlessの名前空間（Namespace）を指定します。そのため、事前にRedshift Serverlessのワークグループ（Workgroup）と名前空間（Namespace）を作成してください。今回は移行対象のVPC/Subnetにリストアするので、下記のいずれかのブログを参考に作成してください。

4. Redshift Serverlessの名前空間を指定してスナップショットをリストアする

[Clusters]-[Snapshots]からリストアしたいスナップショットを選択して、[Restore snapshot ▼]-[Restore to serverless namespace]を選択します。

表示されたダイアログの[NameSpace name]に、先程作成した名前空間（Namespace）を選択します。ダイアログのメッセージにも記載がある通り、このアクションは、Redshift Serverlessのネームスペースにあるすべてのデータベースを置き換えられます。

リストアを開始すると、ワークグループ（Workgroup）と名前空間（Namespace）ともに、Modifyingになります。ともにAvailableになるとリストア完了です。今回はサンプルデータベース（Tickit）のデータが入っているra3.xlplus 2ノードクラスタのスナップショットからのリストアですが、所要時間は約13分でした。

5. アプリケーションの設定

アプリケーションの接続先のRedshiftのエンドポイントを変更します。エンドポイントは、マネジメントコンソールから確認できます。

また、アプリケーションが、Redshift Data APIを利用している場合は、cluster-identityパラメータの代わりにworkgroup-nameパラメータを使用するように変更してください。

マイグレーションの補足

暗号化キーについて

Redshift Serverlessは、暗号化が必須であるためAWS_OWNED_KMS_KEYもしくはCustomer Managed Keyでなければなりません。仮に移行元のRedshift（Provisioned Cluster）が、非暗号化、AWS Managed Key、Customer Managed Keyであろうと、リストアするとAWS_OWNED_KMS_KEYになります。

そのため、移行先のRedshift ServerlessをCustomer Managed Keyで暗号化したい場合は、リストアした後に暗号化キーを変更してください。

マネジメントコンソールのデータベース管理ユーザーの表示

Redshift（Provisioned Cluster）のデフォルトのデータベース管理ユーザー名は、awsuserですが、Redshift Serverlessのデフォルトのデータベース管理ユーザー名は、adminです。リストア後にRedshift Serverlessのマネジメントコンソールからデータベース管理ユーザー名を確認すると、adminと表示されますが、実際には元のawsuserのままです。

なお、データベース管理ユーザー名の表示の不一致が気になるようでしたら、リストア先の名前空間（Namespace）を作成する際に、 [Customize admin user credentials]の[Admin user name]にて、変更することが可能です。

最後に

マイグレーションのザックリした手順は、リストア先のワークグループ（Workgroup）と名前空間（Namespace）を作成して、そこにスナップショットをリストアします。リストアは、至って簡単ですが、Redshift Serverlessは、少なくとも3つのサブネットが必要で、それらが3つのアベイラビリティゾーンにまたがっている必要があります。移行前の環境がこの条件を満たさない場合、VPCへの影響が大きいため、移行時の手順の複雑化やボトルネックになることは、十分に考えられます。ネットワーク関連については、まだ補足したい内容があるのですが、検証が進み次第ブログにまとめたいと思います。

参考文献